Reference-Aware Algorithms by RobertLeahy · Pull Request #2153 · NVIDIA/stdexec

RobertLeahy · 2026-07-31T21:58:04Z

Also contains the following fixes:

continues_on now implements the standard behavior of scheduling when storing the result datums of the predecessor throws
finally now runs the successor even if storing the result datums throws

Does not fully implement P4288R0's design for storage_for_completion_signature because std::tuple is not device compatible.

copy-pr-bot · 2026-07-31T21:58:07Z

This pull request requires additional validation before any workflows can run on NVIDIA's runners.

Pull request vetters can view their responsibilities here.

Contributors can view more details about this message here.

Several headers in exec depend on __storage.hpp.

Allows for template arguments deduced from a completion, for example in: template<typename... Args> void set_value(Args&&...); To be used to determine which completion signature such a completion corresponds to. See P4288.

Provides a turnkey, reference-aware way to store completion signatures for later examination or transmission. See P4288. Note that this implementation diverges from the implementation described in P4288. In order to remain device compatible this implementation stores a __tuple rather than a std::tuple. Therefore storage_for_completion_signature::arguments cannot be provided (since it returns a reference to the directly stored std::tuple, which doesn't exist in this implementation). Moreover to support algorithms which aim to be usable on host and device the implementation in this commit provides both storage_for_completion_signature::forward_arguments and ::__forward_arguments where the latter returns a __tuple and can therefore be marked as being device compatible.

See P4288.

In addition to adding reference awareness also fixes (and brings under test) a previous defect: If decay-copying the result datums threw the successor operation was previously skipped.

See P4288. Also brings the implementation into alignment with the standard: The standard specifies that if storage the value result datums throws the schedule operation is started whereas the previous implementation delivered such a failure inline.

See P4288.

No longer used in favor of storage_for_completion_signatures (which is reference aware).

ericniebler

partial review, more coming...

Also contains the following fixes:

continues_on now implements the standard behavior of scheduling when storing the result datums of the predecessor throws

finally now runs the successor even if storing the result datums throws

would be great if these fixes were in a separate PR so i could merge them early.

ericniebler · 2026-08-05T15:58:11Z

+    using completions_t =
+      decltype(sender_t::template get_completion_signatures<sender_t, ex::env<>>());
+
+    static_assert(ex::__merror<completions_t>);


once i fix the constexpr exception support in get_completion_signatures, this test will fail. i think you could change this to static_assert(!ex::sender_in<sender_t, ex::env<>>).

ericniebler · 2026-08-05T16:02:27Z

+#  define STDEXEC_TUPLE_GET(_Idx)                                                                  \
+    , static_cast<                                                                                 \
+        __copy_cvref_t<_Tuple&&, decltype(static_cast<_Tuple&&>(__tupl).__val##_Idx)>>(            \
+        static_cast<_Tuple&&>(__tupl).__val##_Idx)


why is this change necessary? shouldn't static_cast<_Tuple&&>(__tupl).__val##_Idx already have the correct value category if __val##_Idx has reference type?

Given:

struct foo { int&& bar; };

Both decltype((std::declval<foo>().bar)) and decltype((std::declval<foo&>().bar)) are int&.

std::tuple<int&&> comparison here.

ericniebler · 2026-08-05T16:05:28Z

+        __concat_completion_signatures_t<typename __storage_t::completion_signatures,
+                                         completion_signatures<set_error_t(std::exception_ptr)>>;
+
+      static consteval auto get_completion_signatures()


should the return type of this function always be the same as the type type alias?

ericniebler · 2026-08-05T16:11:30Z

                              && __completes_inline_for<set_stopped_t, _Sender, _Env...>;

-    template <class _Value, bool _Inline>
+    template <class _Sender, class _Promise, class _Value, bool _Inline>


i try to keep sender types out of the types of receivers (and awaitables) because it explodes the types of operation states.

ericniebler · 2026-08-05T16:14:29Z

+      template <class _Arg>
+      constexpr auto operator()(_Arg&& __arg) const -> _Value
+      {
+        return static_cast<_Arg&&>(__arg);
+      }


i think if you change this to:

Suggested change

template <class _Arg>

constexpr auto operator()(_Arg&& __arg) const -> _Value

{

return static_cast<_Arg&&>(__arg);

}

template <class... _Args>

constexpr auto operator()(_Args&&... __args) const -> _Value

{

return _Value(static_cast<_Args&&>(__args)...);

}

you no longer need the specialization for std::tuple.

also, should this be be conditionally noexcept?

ericniebler · 2026-08-05T16:18:22Z

/ok to test 0e15401

RobertLeahy · 2026-08-05T16:35:51Z

would be great if these fixes were in a separate PR so i could merge them early.

I can make separate PRs for both of them but a separate fix wasn't/isn't a natural consequence of this work. The fixes just happened to fall out by accident from converting both of them over to storage_for_completion_signatures.

RobertLeahy added 14 commits August 1, 2026 20:13

Include __storage.hpp From execution.hpp

d65272d

Several headers in exec depend on __storage.hpp.

matching_completion_signature_t

c42b347

Allows for template arguments deduced from a completion, for example in: template<typename... Args> void set_value(Args&&...); To be used to determine which completion signature such a completion corresponds to. See P4288.

__tuple: Reference Aware

6adc374

when_all: Reference Aware

a253c1b

See P4288.

as_awaitable: Reference Aware

cbb75e2

See P4288.

finally: Reference Aware

8c53f49

In addition to adding reference awareness also fixes (and brings under test) a previous defect: If decay-copying the result datums threw the successor operation was previously skipped.

continues_on: Reference Aware

33f33ff

See P4288. Also brings the implementation into alignment with the standard: The standard specifies that if storage the value result datums throws the schedule operation is started whereas the previous implementation delivered such a failure inline.

spawn_future: Reference Aware

d5383c2

See P4288.

exec::when_any: Reference Aware

f8d4a90

exec::fork_join: Reference Aware

6c22d69

exec::split & ::ensure_started: Reference Aware

7b8c4ef

exec::ignore_all_values: Reference Aware

bd47160

Remove __storage.hpp

0e15401

No longer used in favor of storage_for_completion_signatures (which is reference aware).

RobertLeahy force-pushed the p4288_20260731 branch from 990160d to 0e15401 Compare August 2, 2026 00:14

ericniebler requested changes Aug 5, 2026

View reviewed changes

Navigation Menu

Uh oh!

Reference-Aware Algorithms - #2153

Reference-Aware Algorithms#2153
RobertLeahy wants to merge 14 commits into
NVIDIA:mainfrom
RobertLeahy:p4288_20260731

RobertLeahy commented Jul 31, 2026

Uh oh!

copy-pr-bot Bot commented Jul 31, 2026

Uh oh!

ericniebler left a comment

Uh oh!

ericniebler Aug 5, 2026

Uh oh!

ericniebler Aug 5, 2026

Uh oh!

RobertLeahy Aug 5, 2026

Uh oh!

ericniebler Aug 5, 2026

Uh oh!

ericniebler Aug 5, 2026

Uh oh!

ericniebler Aug 5, 2026

Uh oh!

ericniebler commented Aug 5, 2026

Uh oh!

RobertLeahy commented Aug 5, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

RobertLeahy commented Jul 31, 2026

Uh oh!

copy-pr-bot Bot commented Jul 31, 2026

Uh oh!

ericniebler left a comment

Choose a reason for hiding this comment

Uh oh!

ericniebler Aug 5, 2026

Choose a reason for hiding this comment

Uh oh!

ericniebler Aug 5, 2026

Choose a reason for hiding this comment

Uh oh!

RobertLeahy Aug 5, 2026

Choose a reason for hiding this comment

Uh oh!

ericniebler Aug 5, 2026

Choose a reason for hiding this comment

Uh oh!

ericniebler Aug 5, 2026

Choose a reason for hiding this comment

Uh oh!

ericniebler Aug 5, 2026

Choose a reason for hiding this comment

Uh oh!

ericniebler commented Aug 5, 2026

Uh oh!

RobertLeahy commented Aug 5, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants